home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1823 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB
  1. Path: news.rmii.com!usenet
  2. From: jcoffin@rmii.com (Jerry Coffin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Name-mangling standard
  5. Date: Sat, 13 Jan 1996 05:03:11 GMT
  6. Organization: TAEUS
  7. Message-ID: <4d7aec$67l@natasha.rmii.com>
  8. References: <20c.32169.607@newage.com.ar> <4bsnbu$5mu@mujibur.inmind.com> <30EDC013.7C780E5E@cims.nyu.edu> <DL1pqE.KKq@infosoft.com>
  9. NNTP-Posting-Host: slip875.rmii.com
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. jgalt@infosoft.com (John Galt) wrote:
  13.  
  14. [ ... ] 
  15. >For the same reason, I'm against the concept of "undefined behavior" in the C
  16. >and C++ standards.  No program that has "undefined behavior" should compile.
  17.  
  18. Here I have to disagree.  On one hand there are lots of things it's not
  19. reasonable to try to define in a portable fashion.  OTOH, not all
  20. programs are meant to be portable.  For instance, if I'm writing
  21. something like a device driver, it makes little difference that I
  22. regularly invoke undefined behavior, as long as I know that the system
  23. for which the device driver is written handles it in a particular
  24. fasion.
  25.  
  26. To give some specifics: if I'm writing a console driver on a PC, I'm
  27. likely to do something like this:
  28.  
  29. int *screen = (int *)0xb80000000;
  30.  
  31. which clearly isn't portable, and never will be.  Attempting to call the
  32. effects anything other than undefined would be sheer folly.  Yet if it's
  33. made illegal, it forces me to resort to assembly language instead,
  34. hardly an attractive proposition.
  35.  
  36. In addition, the basic nature of much undefined behavior makes it
  37. impossible to detect at compile-time.  For instance, if I have something
  38. vaguely similar to:
  39.  
  40. char x[1234];
  41. unsigned subscript;
  42.  
  43. cout << "Please enter a number: " << endl;
  44.  
  45. cin >> subscript;
  46.  
  47. cout << "\n%d", x[subscript];
  48.  
  49. How do you propose to write a compiler that will know before hand
  50. whether the user will enter a number greater or less than 1233?  It's
  51. obviously impossible.
  52.  
  53. Even if we allow the detection to be moved to compile time, this
  54. mandates range checking on all array accesses, which is quite expensive,
  55. and something many would be quite displeased with.
  56.  
  57. Adding bounds checking that works properly on dynamically allocated
  58. arrays is somewhat difficult itself.  For instance, if I pass a pointer
  59. to the middle of a dynamically allocated array to a function, then the
  60. function accesses the memory, the run-time needs to be able to deduce
  61. from the pointer what block of memory it's received a pointer to, and
  62. consult the proper information to figure out what's legal with this
  63. particular pointer, and allow things like negative subscripts in this
  64. particular case.  In cases where bounds checking is really important, it
  65. doesn't seem particularly onerous to use something like:
  66.  
  67. checked_array<char> x(1234);
  68.  
  69. and define the semantics as I see fit in checked_array.  This of course
  70. raises another point: assuming we mandate a run-time that range checks
  71. all memory accesses, what do you propose that it do when it detects such
  72. a thing?  It's obviously a bit late to prevent compilation.  In C++ it
  73. can throw an exception (which a checked_array class can as well) but you
  74. also mention this with C?  What should happen in C?  You could mandate a
  75. call to abort, but this "cure" may well be much worse than the disease.
  76.  
  77.  
  78. Ultimately, I think compiler technology has progressed to the point that
  79. some things the C standard considers undefined behavior can and should
  80. be detected and dianosed. However, detection of _all_ undefined behavior
  81. would require a huge amount of run-time checking with concommitant loss
  82. of anything approaching efficiency and would likely make C++ a bit nicer
  83. for the academics, but destroy its usefulness.
  84.     Later,
  85.     Jerry.
  86.  
  87. /* I can barely express my own opinions; I certainly can't
  88.  * express anybody else's.
  89.  *
  90.  * The universe is a figment of its own imagination.
  91.  */
  92.  
  93.